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The Section 514 Single Event Effects (SEE) Testing and Analysis Group has performed 
a series of SEE tests of certain strategic registers of Intel's 80386DX CHMOS IV 
microprocessor. Following a summary of the test techniques and hardware used to gather 
the data, we present the SEE heavy ion and proton test results. We also describe the 
registers tested, along with a system impact analysis should these registers experience a 
single event upset. 
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Single event latchup (SEL) and single event upset (SEU) may be induced in devices 
operating in space by cosmic rays and/or solar flare particles. SEL occurs when a cosmic 
ray turns on a parasitic bipolar PNPN structure. Device malfunction with excessive 

“^aoT" 8 a 'V he ”*>?** - I—* catastrophic 

“" 'f': SEU 13 asoft “ ror *at occurs when a cosmic ray causes the data stored in a 

circuit element to flip to the opposite state. 

Na1Tm SE ^ data f0r c the Imel 80386DX m * cro P rocessor is of importance to the 
na ^ Microelectronics Space Radiation Effects Program (MSREP), because several 

^oJ ^Xse703 C 86DX e r f* ^ ^ ^ ^ZsZn 

freedom will use 80386DX-based computers for its data management system and the 
Small Explorer Data System (SEDS), a subsystem of die Sok lol, 

processor^ ^ Expl ° rer (SAMPEX ) ™ssion, uses an 80386DX as its main 

From an SEU standpoint, 80386DX registers can be placed in one of three 
ssifications. application level, system level or hardware level. Application level registers 
perform functions which are not generally crucial to the integrity of a systen^Two 
examples are the extended source index (ESI) register, used to mole bloclTof datl in 
memory, and the emended BX (EBX) register, used for temporary data storage System 
ievel registers on the other hand, can have a direct impact on the integrity of a ZZ 
should they be upset. Examples include the global descriptor table register (GDTR) 

z TJZTri: h T e d mory rr gement> , and the task *** 

management The hardware level register classification covers everythin* that cannot be 
irmly addressed on the software level. These W es of renters 2 the pmm i" ter^ 
of then abihty to affect system integrity. Even though Intel has refused t<f release details 
on these types of registers, a few can be tested. An example of a hardware £T S 

A C a V KtCd “ ' he gr ° Uf> ° f 34 address itches behind the 80386DX address pins 
Appendix A summarizes all known 80386DX registers. E ' 

Previous testing' concentrated mostly on the less important application level registers 
Fmth, reason JPL has undertaken an effort to gathe", dara on^he crud^ZS 
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ft ryiRfinx OV F RY ifw and BACKGROU ND 


i i RfnfifiDX ; s a very high performance Complex Instruction Set Computer 
The Intel 80386DX is a vay mgnp instruCtion s at a peak rate of 8 to 9 

(CISC) microprocessor that * : 33 MHz ^ ^ ^ ^ ^ ^ 

[Kovide of 66 rn.gaby.es per 

and memory management functions in parallel, wrth btde or no time penalty. 

The 80386DX is amiable in three speeds: 20, 25 and JJ 

possibly 25 ^ P^ * Cre ^TaH “‘“ent versions are implemented in Intel's 
a * 275,000, butthis ^tLlTSTrhXn^ can be 

tr£iSK=S5£ 

SSrat an uX”.be CHMOS 'ill' pans are on an epitaxial substrate while 
the CHMOS IV parts use twm-wells. 

■ r t L p jiotfifiDX which include the 80386SX with a 

!""«» Z ^rS» microcontroller; and the two-chip 80386SU 

pX a high level of 

Anh386DX wXatng other attributes 

Xu^sJofXcrons with 0 ; 9 microns 

sunc design, AMD needed - ™« — ^ 

Intel used, ^ For a total of 160,000 To «Ue £££££* jftwS 
AM386DX device was also tested. Its latchup (SEL) threshold occurre 

MeV/(mg/cm 2 ). This result led us to discontinue the test. 


2 Midi»el Slater, "AMD Formally Announces A,u386DX-. Mnvpnvo.w K*~t. Vol. 5 No. 6, April 3, 
1991, p. 6. 

r anTRAD Y and its variants, however IBM uses them strictly 

^ - dor - ibm » thercfore ’ is not a sccond sourcc in ** 

strict sense. 
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MODES OF OPERATION 


The 80386DX has three distinct modes of operation: 1) real address, 2) protected virtual 
address, and 3) virtual 8086. Following is a description of these modes. 

1) Real Address Mode 

In real address mode, the processor provides fast execution of 8086 instructions in an 
unprotected environment; i.e., the program that is executing "owns" the processor and 
can do anything it likes, including crashing the system. This mode of operation also 
duplicates the 8086 segmented addressing model where logical addresses are combined 
with segment information to form linear addresses which map directly to the physical 
address space. Real address mode allows use of some of the 80386 enhancements such as 
a few new addressing modes, access to some 32-bit registers and full 32-bit address space 
with the appropriate software instruction prefixes. The original Intel 8086 only has 16- 
bit registers and a 20-bit address space. 

2) Protected Virtual Address Mode 

This operational mode adds a new type of address translation, paging, and increases the 
maximum segment size to 32 bits vs. the real address mode's 16-bit segments. Paging and 
segmentation allow an operating system to translate addresses. On the 80386DX this 
means that any logical address supplied by a programmer goes through a level of 
indirection (segmentation), becoming a linear address. This linear address is then subject 
to yet another level of indirection (paging), becoming a physical address which is used to 
drive the address bus. This address translation mechanism is a very important concept, 
because it allows an operating system to mark certain areas of memory as unavailable to a 
task, or even invisibly mask out portions of memory. 

The 80386DX can also implement demand paging to create a virtual environment for 
programs. In this case, neither the program code nor the application programmer needs 
to know how much RAM is available, or where it is located. If a program makes 
reference to a nonexistent page of memory, the 80386DX will trap the reference and call 
a page fault handler , which will then retrieve the desired data from a mass storage device, 
such as a hard disk, and place it in memory. The previous memory contents are 
effectively swapped with the data on the hard disk. The 80386DX can provide as much 
as 64 terabytes of this virtual memory. 

Multitasking is one of the most powerful features of the 80386DX. At the hardware level 
it is designed to keep track of an almost limitless number of tasks. A task can be one of 
many programs that appear to be running simultaneously, but in actuality the processor 
allows each task to run for a certain amount of time before a task switch takes place and 
the processor gives its resources to another task. Task switching is very fast, as only one 
assembly instruction is needed to perform the switch, with the rest of the operation being 
handled by on-chip hardware. 


3 



Privilege Protection is implemented in hardware on the 80386DX and is a way of making 
sure that unfriendly tasks do not affect the operation of other tasks (most importantly, 
the operating system itself) that may be running concurrently. With this method, every 
piece of code and data is assigned one of four privilege levels called rings, where ring 0 
has the highest priority and ring 3 the lowest. The 80386DX automatically performs this 
privilege validation on every memory cycle. This privilege validation takes form in five 
ways: type check, limit check, restriction of addressable domain, restriction of procedure 
entry points and restriction of instruction set. If the task is privileged enough, its memory 
access will be granted. If not, the processor will deny access and generate a privilege 
exception; the operating system will then take over and decide what to do with the 
offending task. 

3) Virtual 8086 Mode 

Virtual 8086 mode, a sub-mode of the protected mode, establishes an 8086 execution 
environment within the protected, multitasking environment of the 80386DX, thus, 
allowing an operating system to execute multiple 8086 and 80386DX programs 
concurrently. 

TFST PHILOSOPHY 

In this SEE test, as with all microprocessor tests performed by JPL, the test philosophy 
is to isolate individual registers, load them with known data, and expose them to the 
heavy ion source, while monitoring register contents. When an SEU occurs, the error is 
counted, the device is reset to a known state (usually the post-reset state), and then set up 
for the next possible SEU. This approach yields absolutely traceable data in terms of 
which elements and how many bits are upset in an extremely complex device. Cross- 
section and threshold calculations may be calculated with great accuracy and confidence 
for a given set of device elements. This allows the system engineers to build an accurate 
cross-section for a device from individual register cross-sections, based on the actual 
device application. In the 80386, for example, the Translation Lookaside Buffer (TLB), 
which is used in paging mode, contains more than 1600 bits which have a major impact 
on the total device cross-section. If the TLB is not used in an application (i.e. paging is 
turned off), however, its cross-section may be disregarded by the systems engineer. This 
approach also helps the vendor identify those areas of a chip that can profit by hardness 
redesign. 

Testing with an instruction mix, on the other hand, reveals very little information about 
the radiation hardness of a complex device other than the fact that something happened 
to it when it got "hit". The cross-section obtained with an instruction mix tells nothing 
about individual elements of interest to the systems engineer. This is true for a number of 
reasons: so many operations are occurring at many levels in an instruction mix that the 
cause of an error, and a possible correction procedure, may never be determined; the 
experimenter has no idea what the state of the device should be when an error occurs; the 
device may be flagging errors when none are present after the first one, simply because 
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that first one sent the device into an unknown state; or the instruction mix may not 
represent the normal operating state of the device in a real-world application. 

: AQK CIRCUIT” FOR RFfilfiTFR TPRjg 

The AOK circuit", as it is informally known, is a circuit located on the DUT card which 
examines the state of the DUT at the time the test system would expect valid register 
data on the data bus. If the processor state is valid, a comparison is made between the 
data bus and a constant stored in a series of four 2K by 8-bit EPROMS. This 
comparison circuitry can compare byte, word, and double-word values that are byte 
ahgned on the data bus. If the comparison determines that the data is invalid, a signal is 
sent off-card to a counter, indicating that a valid SEU has occurred. If the processor state 
is invalid, the test card does not "look” at the data bus, but instead sends out a signal to a 
second counter, indicating that an unknown portion of the DUT had been subjected to 
an SEU and was not functioning correctly. 

mil CARD AND TEST SY STEM OVFRVIFW 

Due to the high level of complexity of the 80386DX, and difficulties inherent in testing 
such a complex device, a highly integrated approach to device testing has evolved. The 
DUT card actually contains a complete custom onboard microcomputer and monitoring 
circuitry, and as such becomes a part of the test system. 

The test card is a 7.50" x 7.30" copper-clad vectorboard onto which the DUT and 
peripheral circuitry are soldered and/or wire-wrapped. The copper cladding provides a 
ground plane, which helps reduce "ground bounce" by minimizing ground inductance. 
Jhe DU 1 and peripheral logic are powered and monitored separately by Hewlett- 
Packard power supplies using 4-wire techniques. The test card is controlled from outside 
the test chamber by a Hewlett-Packard 16520A 50-megabit/second pattern generator. A 
Hewlett-Packard 16515A one gigahertz timing analyzer can be used to observe the 
behavior of the DUT in the beam. The test card, in return, provides signals that indicate 
the status as well as the types of errors that have occurred. These signals are sent to a set 
of digital display counters for external monitoring. This test setup can operate 
synchronously at clock rates (at the CLK2 input) of up to 25 MHz while sorting and 
categorizing errors at a rate of over 12,000 per second. 

For reference, Figure 1 is a one-to-one scale drawing of the test card, and Figure 2 is a 
test setup cabling diagram, showing all stimulus, feedback, and power connections 

needed to perform a SEE test. Additionally, a complete test card schematic is included in 
figure 3. 

TEST METHODOI onv 

During the test, the microprocessor will execute the instructions necessary to exercise the 
^™P mte re g ist er. These instructions are located in four onboard 256K by 8-bit 
ROMS that operate with no wait states. As few instructions are needed to test a 
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Test Card Schematic 
Figure 3 





register, and there are many possible tests (i.e., register and pattern combinations) it is 
advantageous to page physical memory into the address space of the microprocessor. The 
type of test to be performed is then selected remotely by the pattern generator which 
selects the appropriate memory page. Program memory on the test card is organized as 
128 pages, each containing 256 double-words. This memory is not decoded, meaning 
that each kilobyte page wraps around many times, occupying the entire address space. 
This allows the reset code to be executed at FFFFFFFOh, while non-maskable interrupts 
can still be serviced at 00000008h, all in one page. 

This paging scheme also gives the test system the advantage of being able to control the 
type of instructions that the DUT can execute at any given time. The test system, as an 
example, can dynamically change the page to one containing all HLT (halt) instructions 
during the shutdown period of a test cycle, when the DUT is integrating errors. Should 
the DUT come out of shutdown mode, perhaps due to an extraneous interrupt, and start 
to execute code, the processor would be placed back into shutdown mode because its 
entire address space is filled with halt instructions. 

Also on-board the test card is the AOK circuitry described earlier and necessary to help 
ensure the correct classification of errors. 

As an example of a typical test run, the test system performs the following steps to test 
the CR3: 

1) The DUT is reset, synchronizing it with the test system and placing it into a known 
state. The test card also sends a signal to an external counter, signaling that another test 
sequence has started. 

2) The DUT initializes itself then starts execution at FFFFFFFOh, which contains a 
sequence of instructions that loads the CR3 with the desired pattern. Specifically, a 
MOV EAX,[32-bit pattern], then a MOV CR3.EAX. 

3) The DUT then executes a HLT instruction, placing it into shutdown mode where it 
will lie dormant. 

4) After the DUT acknowledges entry into shutdown mode, the test system changes the 
memory page to one that contains all HLT instructions (i.e., one that is filled with F4h). 

5) The test system continues to clock the DUT for a period equal to about 80 percent of 
the total test cycle time. It is during this period that the actual errors are integrated in the 
register under test. 

6) The test system returns the original memory page to the 80386DX address space. 

7) The DUT is brought out of shutdown mode with a non-maskable interrupt (NMI). 
To acknowledge the NMI, the 80386DX must first get the NMI handler address from 
location 00000008h in physical memory, which contains OOOOOlOOh. 
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8) The processor starts to execute code at OOOOOlOOh and is 

move the contents of CR3 out onto the data bus. Specifically, a MOV EAX, CR3 then 
MOV DX, 5550h and finally an OUT DX, EAX are executed to achieve this result. 

9) At the point when the 80386DX would normally transfer the data onto the data bus, 
the test system examines the processor state to verify that a properly aligned I/O write is 
taking place. If the processor is not performing normally, the test card sends a signal to a 
counter indicating that the processor was found to be in an invalid state, and takes no 
further action. If the processor state is valid, the data bus will be checked for errors. If an 
error is noted the test card increments the external "valid SEU" counter. 

10) The test sequence starts all over again at #1, when the pattern generator loops back 
and resets the DUT. 

SPAnF STATION FREEDO M’S OPERATING SYSTEM 

The operating system chosen by IBM for Space Station Freedom (SSF) is LynxOS from 
Lynx Real-Time Systems Inc. in Campbell, California. LynxOS is a 
multitasking/ multiuser operating system that is compatible with the two leading versions 
of UNIX: AT&T System V and Berkeley 4.3 BSD. LynxOS also conforms to seve 
important standards: POSIX (portable operating system interface for computer 
environments, IEEE 1003.1), real-time extensions to POSIX (IEEE 1003.4), and Ada 
(the language of choice on SSF) bindings for POSIX (IEEE 1003.5). 

During telephone discussions with George Kohli (Lynx Software Engineer), Mike 
Bunnell (another Lynx Software Engineer) and Paul Panepinto (Lynx Sales Manager) l 
was verified that LynxOS would make use of the 80386DXs protected virtual address 
mode of operation, with paging enabled. It was also ascertained that LynxOS was i bought 
"off the shelf’ for use on SSF and would not be modified before flight. This last fact 
makes system level register data even more important because LynxOS vm dngped for 
real-time control applications on Earth where SEE is n °t a problem. Thus, LynxOS s 
not "SEU aware" and would not protect the system from SEUs. Although, to be fair, 
should be pointed out that no operating system could possibly prevent all such damage, 
but steps could certainly be taken to prevent some SEU related damage. 

RFOIRTER DESCRIP T ION AND SYSTEM IMPACT ANALYSI S 

Below is a description of the registers tested by JPL to date. Also included is .a general 
analysis of the system impact should that register become corrupted ^ ^ SELLTlu 
analysis applies to any operating system that uses the full capabilities of the 80386 DX s 
protected Virtual address mode, including LynxOS. In the context of this analysis 
"crashing” generally means that the 80386DX itself enters shutdown mode , which can 
happen for several reasons. As an example, if another exception occurs while the 
80386DX is processing a double-fault exception it would signal that shutdown was 
imminent and immediately do so. To protect the overall system, an operating system can 
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also initiate shutdown mode by executing a HLT instruction from ring 0. A 80386DX in 

shutdown mode would require a non-maskable interrupt or reset before it would begin to 
execute instructions again. 6 

CONTROL REGISTER 3 (CR3) 

The CR3 is a system level register containing the 32-bit, page aligned, physical base 
address of the page directory. For this reason, it also is sometimes called the Page 
Directory Base Register (PDBR), which is a data structure in memory that contains an 
array of 32 -bit linear addresses. These addresses point to yet another data structure in 
memoiy called a page table , containing an array of 32-bit physical addresses. The 
operating system has the option of having one global page directory for all tasks, one 
page directory for each task or somewhere in between the two. 

To translate a linear address to a physical address the 80386DX's paging hardware must 
perform many steps. The first step is to receive a 32-bit linear address from the 
segmentation hardware and split it into three components: a 10-bit page directory offset, 
a 10-bit page table offset, and a 12-bit page frame offset. Using the contents of the CR3 
as a base address and the page directory offset as a pointer, the paging hardware looks up 
a page table base address in the page directory. The paging hardware then uses the page 

table offset to look up an entry in the selected page table. This entire process is outlined 
in Figure 4. 
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Should the CR3 experience a single event upset, the current task would lose track of ^ 
page tables and do anything from causing a protection violation to crashing ^e"tue 
operating system. The amount of damage caused to the system would depend largely on 
the privilege level of the task that experiences the error and the amount of intelligence 
built into the operating system to detect and, if possible, correct such occurrences. 

As an example, the operating system, which operates at the highest 

ring 0), could easily crash if it lost track of some, or all of its data and code^O 

hand, if an application running at the lowest prmlege (i.e., ring 3) lost its data and code, 

that application would eventually cause an exception that would have to be handle y 

one of the operating system’s exception handlers. The operating could l be 

unaffected if the protection violation initiated a task switch which caused the CR3 tobe 

reloaded with a valid address from the fault handler's Task State Segment (TSS - a type 

of segment saving processor state information needed to restore a task). If the protection 

fault ^oes not cause the CR3 to be reloaded, which would occur for 

handler were called through a call gate, the operating system itself would become subject 

to a corrupted CR3. 

Because all page lookups are cached (see TLB, below), the possibility arises that all page 
formation 1 for a given task would reside in the TLB. This would happen if the sum of 
all pages were no greater than 128 kbytes (32 pages x 4 kbytes per page). In this case the 
sysfem would be unaffected because CR3 would eventually be refreshed from that tasks 

TSS upon successive task switches. 

All 32 bits of CR3 were tested with either an all ones, all zeros, checkerboard 
(AAAAAAAAh), or inverse checkerboard (55555555b) pattern. While testing the 
pattern was present in CR3 eighty percent of the time. The other twenty percent of the 
time was demoted to initializing the processor after reset and executing the actualcode 
necessary to get information into and out of CR3. It should be noted that because the 
page director^ must be page aligned, the 12 least significant bits of CR3 are assumed to 
be zero by the 80386DX and are ignored. 

TRANSLATION LOOKASIDE BUFFER (TLB) 

The TLB is a four-way set-associative 32-entry cache that buffers page table accesses^ 
Without this buffering, the 80386's paging hardware would have to access two levds of 
tables for each memory access, an unacceptable performance penalty. Each entry m t 
TLB holds the upper twenty bits of a linear address, the upper enty 
associated physicaTaddress and some tag bits used for data protecuon and mche 
implementation. The linear address field and tag bits are implemented in content- 
addressable memory (CAM) while the physical address field is implemented using 

random access memory (RAM). 

One cache entry from each of the four sets was tested. All forty bits of the linear and 
physical addresT fields from this entry were tested using either an all ones, all zeros, 
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checkerboard (AAAAAAAAh), or inverse checkerboard (55555555h) pattern. During 
testing, the pattern was present in the cache entry eighty percent of the time. The other 
twenty percent of the time was devoted to initializing the processor after reset and 
executing the actual code necessary to get information into and out of the entry. Of the 
approximately 1600 bits, 160 bits were tested for SEU. 

GLOBAL DESCRIPTOR TABLE REGISTER (GDTR) 

The GDTR is a system level register that holds the 32-bit linear base address and 16-bit 
limit of the Global Descriptor Table (GDT). The GDT is a data structure in memory 
that holds all non-interrupt related segment descriptors that are global to the system. A 
segment descriptor is an eight-byte data structure which provides the 80386DX with 
information about the type, size and location of a memory segment, as well as necessary 
segment attributes. The individual descriptors are selected by an address offset stored in a 
segment selector register. Segment selectors can only point to certain types of descriptors 
to which they are matched. As an example, the Task Register (TR) must always point to 
a TSS. In any 80386DX protected-mode operating system there must be at least three 
descriptors defined in the GDT: null, code, and data descriptors. LynxOS, like UNIX, 
does not support a segmented memory architecture and therefore would not likely have a 
need to define a great number of descriptors in the GDT. 

Should the 16-bit limit portion of the GDTR experience an SEU, the result would 
depend on whether this 16-bit value was increased or decreased. Should the limit be 
increased, the GDT would possibly alias, or overlap, another segment(s) in memory. 
This aliasing would have little or no effect on the system because neither the portion of 
the operating system that maintains the GDT or the task(s) that owned the aliased 
segment(s) would know about this new limit. The task that owned the aliased segment 
would just continue using it as it had before the SEU. The operating system generally 
would not write new GDT entries in this aliased area because the maximum GDT limit 
would be determined once, at boot time, and never exceeded. Even if the operating 
system had a provision to dynamically allocate GDT space, it would have to first check 
that it was not going to try to allocate memory that belonged to another segment. At this 
time the operating system would determine that it would indeed overlap another segment 
and either move the "offending" segment out of the way or relocate the GDT to a larger 
portion of memory. 

If the GDT limit were decreased and then a task attempted to use a selector value beyond 
the new limit, one of two possible types of exceptions would be generated: a General 
Protection Exception or an Invalid TSS Exception. The latter exception would occur 
only during a task switch when the 80386DX would normally try to validate the new 
TSS. If the operating system were SEU-aware it might incorporate some code in these 
two exception handlers that would compare the GDTR limit with the correct value that 
would be kept in memory. The operating system in this case would be able to recover 
gracefully, with no system impact. If the operating system were not SEU-aware, the 
operating system would lose all segments associated with the "lost" descriptors. Although 
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it is easy to imagine the system crashing under such circumstances, the actual amount of 
damage to the system would depend directly on the number and criticality of the lost 

segments. 

The other portion of the GDTR, the 32-bit base address, is extremely important to an 
operating system because it defines the GDT location in memory. If the GDT were to 
become misaligned, or lost altogether, the system would be put into a state of chaos and 

eventually crash. 

All 32 bits of the GDTR's base address portion were tested with either an all ones, all 
zeros, checkerboard (AAAAAAAAh), or inverse checkerboard (55555555h) pattern. 
While testing, the pattern was present in the GDTR eighty percent of the tirne. The 
other twenty percent of the time was devoted to initializing the processor after the reset 
and to executing the actual code necessary to get information into and out of the GD 


INTERRUPT DESCRIPTOR TABLE REGISTER (IDTR) 


The IDTR is a system level register that holds the 32-bit linear base address and 16-bit 
limit of the Interrupt Descriptor Table (IDT). This IDT, like the GDT, is a ta 
structure in memory that holds segment descriptors that are global to a system. Unlike 
the GDT, the IDT can only contain interrupt or exception related segment descriptors. 


The IDT associates each exception or interrupt vector with a segment descriptor for the 
task or procedure which services the associated event. To look up the corresponding 
descriptor, the processor scales the interrupt or exception vector by eight the number ot 
bytes per descriptor, this value is then compared against the IDT limit. If this value does 
not exceed the limit, it is added to the base address to form the 32-bit linear address of 
the desired descriptor. If this value does exceed the limit, the processor will enter 
shutdown mode immediately. 

Should the 16-bit limit portion of the IDTR experience an SEU, the result would 
depend on whether the 16-bit value increased or decreased. Should the limit increase, the 
IDTR might alias to one or more different segments in memory. Aliasing would ave 
little or no effect on the system because neither the portion of the operating system that 
maintains the IDTR or the task(s) that owned the aliased segment(s) would know about 
this new limit. The task that owned the aliased segment would continue using it, j ust as “ 
the SEU had not occurred. The operating system generally would not write new IDT 
entries in this aliased area because the maximum IDT limit would be determined once, at 
boot time, and never exceeded. Even if the operating system had a provision to 
dynamically allocate IDT space, it would have to first check that it was not going to try 
to allocate memory belonging to another segment. At this time, the operating system 
would determine that it would indeed overlap another segment and either move the 
"offending" segment out of the way or relocate the IDT to a larger portion of memory. 
On the other hand, if the IDT limit were decreased and the system was called upon to 
service an interrupt whose segment descriptor lay outside the limit, the 80386 would 
immediately enter shutdown mode, hanging the system. 
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If the 32-bit base address portion of the IDTR were subject to an error, the IDT would 
become misaligned or lost altogether, the operating system would not be able to handle 
interrupts or faults and would eventually crash. 

All 32 bits of the IDTR's base address portion were tested with all ones, all zeros, 
checkerboard (AAAAAAAAh), or inverse checkerboard (55555555h) patterns. During 
testing, the pattern was present in the IDTR eighty percent of the time. The other 
twenty percent of the time was devoted to initializing the processor after reset, and 
executing the actual code necessary to move information into and out of the IDTR. 

EXTENDED AX REGISTER (EAX) 

The EAX register is one of eight general purpose 32-bit registers on the 80386DX. 
These registers are used to hold operands for logical, arithmetic and address calculations. 
The EAX is one of the most widely used registers in the 80386, and as such may contain 
anything from a system-critical initialization procedure pointer, a seldom-used non- 
critical flag or no useful information whatsoever during the occurrence of an SEU. The 
operational result of an SEU occurring in the EAX is, therefore, extremely unpredictable, 
but has a high probability of not being catastrophic. Because the CPU mostly executes 
tasks that are at high protection levels (i.e., higher ring levels), any serious error caused by 
an SEU will be trapped by the operating system and cleaned up. 

All 32 bits of the EAX register were tested with all ones, all zeros, checkerboard 
(AAAAAAAAh), or inverse checkerboard (55555555h) patterns. During testing, the 
pattern was present in the EAX register eighty percent of the time. The remaining 
twenty percent was devoted to initializing the processor after reset, and executing the 
actual code necessary to move information into and out of the EAX register. 

TEST RESULTS 

1) Heavy Ions 

The CHMOS IV Intel 80386 was tested at the Brookhaven National Laboratory (BNL) 
in May and July 1991. It received a partial characterization at room temperature at 25 
MHz (CLK2 input) of five function blocks (see Table 1) for ions spanning a LET range 
of 2.5 to 60 MeV/(mg/cm 2 ). All data were taken with ions at normal beam incidence 
(theta=0), because the package configuration does not permit testing at oblique angles. 
The data, averaged over two or more of the test parts (S/N 1259, 1260, 1261 and 1262) 
and normalized to cross section per bit for each function block, are given in Figure 5 for 
most of the seven test ions shown in Table 2. It was found during the test that all four 
test sets of the TLB exhibited an identical soft error response independent of "all l's" and 
"all 0's" test modes, so the plot condenses that result. When a flux comparison (10 4 vs. 
10 5 ions/cm 2 ) showed no difference in SEU or SEL results (as expected), most of the 
remaining data were taken in the checkerboard (CB) mode at the higher flux (10 s 
ions/cm 2 per second for a total of 10 6 ions/cm 2 in ~10 second runs). 
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PARTIAL CROSS SECTIONS (cm 2 PER BIT) 


JPL INTEL 80386 SEE TEST DATA 

FUNCTIONAL BLOCKS (CB) MAY AND JULY 1991 



Figure 5 
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The data of Figure 5 show no significant difference in either partial cross section or soft 
error threshold among the five function blocks tested. The data for LET=2.5 showed no 
soft errors for any of the five function blocks for each of two devices (S/N 1261 and 
1262) for 10 7 132 MeV O ions/cm 2 per run. Data for LET=60 showed only latchups 
with large currents in the 300 mA to 942 mA range, which obscured any soft errors. 
(NOTE: the latchup cross section was ~6xl0' 5 cm 2 per device for 320 MeV I.) The data 
at LET=40 showed soft errors as well as an occasional latchup, so it is very near the 
latchup threshold. One device was tested at 5.5 V and 4.5 V bias, with no significant 
difference in response to the two bias levels. Note that the observed high current latchups 
were of the classic, potentially catastrophic type caused by a single particle, completely 
independent of flux, rendering the device non-fimctional. It should be noted that S/N 
1259 was destroyed during testing due to latchup. Classic latchups are not to be confused 
with small-current, "micro-latchup" phenomena observed by others. 

The data may be summarized as: latchup threshold LET=40 MeV/(mg/cm 2 ) with 5.5 V 
bias and soft error threshold LET=3.5 ± 1 MeV/(mg/cm 2 ) with 4.5 V bias, all at ambient 
temperature. 

A Comparison — Tom Scott 4 was on-site for the May test. He has compared his IBM 
data to JPL’s for the EAX and TLB registers, and reports that the results from the two 
organizations are nearly identical. He concurs that JPL's CR3, IDTR, and GDTR tests 
are an important addition to the microprocessor characterization — in part, because of 
the critical nature of upsets that occur for those functions. 


Table 1. Intel 80386 Function Blocks Tested 


Function Block 

Bits Tested out of Total 

EAX - Extended AX, general purpose register 

32 out of 32 

*GDTR - Global Descriptor Table register 

32 out of 48 

TDTR - Interrupt Descriptor Table register 

16 out of 48 

*CR3 - Control Register 3, Page Directory 

32 out of 32 

TLB - Translation Lookaside Buffer: 


Set 0 

40 out of 1632 

Set 1 

40 out of 1632 

Set 2 

40 out of 1632 

Set 3 

40 out of 1632 


^Heretofore untested function blocks. 


NOTE: An "all IV, "all 0's", checkerboard (CB) and inverse CB are available for all function blocks. 


"Tom Scott, Private Communication, 1992. 
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Table 2. Intel 80386 - BNL Test Ions (May and July 1991) 


LET [MeV/(mg/cm 2 )] 

Ion and Energy 

Range (microns) 

2.5 

132 MeV O 

150 

4.5 

51 MeV O 

38 

7.6 

194 MeV Si 

81 

13 

153 MeV Cl 

44 

24 

255 MeV Fe 

44 

40 

285 MeV Br 

37 

60 

320 MeV I 

33 


2) Protons 

Proton data were taken at the Harvard Cyclotron in June 1991. Proton energies were 160 
MeV (an undegraded beam used for only a few early measurements) and a set of 148, 90 
and 50 MeV energy levels obtained by passing the beam through an appropriate 
degrader. The lower energy beams yield a larger more uniform beam cross section at the 
expense of a ten- to twenty-fold reduction in beam flux, and are therefore desirable only 
when test conditions can accept the lower flux (fluence) level. 

The test results for five parts are summarized in Table 3. In the first run with part S/N 
1263, 1.4xl0 n 160 MeV p/cm 2 were delivered to the "all-ones" mode of CR3, causing 
two "not-AOK" soft errors. The "not-AOK" error designation refers to upsets of some 
susceptible bits located outside the tested function block. A subsequent run of this part 
for the same function configuration induced device failure (evidenced by tester runaway) 
after 5.7xl0 10 p/cm 2 for a total of 2.0x10* 1 p/cm 2 — or 15 Krads. This dose is somewhat 
lower than the range of the total ionizing dose (TID) tolerance of 20 to 24 Krads 
determined from IBM's Gamma environment 5 . For subsequent runs, the proton fluence 
was limited to 10 to 15 Krads, and there were no further TID device failures. Because of 
these constraints on total device fluence (~10 n p/cm 2 ), there were also very few errors, 
and the statistics do not determine whether they are occurring randomly among the five 
tested function configurations shown in Table 1. 


5 Ibid, footnote 1. 
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Table 3. Summary of Proton Soft Errors for Intel 80386 


S/N 

Total Fluence 
(10 11 p/cm 2 ) 

Energy 

(MeV) 

Not AOK 

SEUs 

Pattern 

Test Mode 

Failure Site 

1263 

2.0 

160 

2 

0 

Ones 


Unknown 

1259 

1.4 

160 

1 

1 

Ones 

All 5 

GDTR 

1260 

1.13 

148 

0 

0 

CB 

All 5 



1260 

1.13 

148 

0 

1 

CB 


CR3 

1261 

1.36 

148 

0 

0 

CB 

All 5 


1262 

1.7 

148 

1 

0 

CB 

All 5 

Unknown 


Conclusion - The approximate overall cross section is calculated by adding up all the 
errors and fluence for all devices given in Table 3. Thus: 

6 errors / {(average ~50 bits) x 8. 72x10* 1 p/cm 2 ) 

or cross section = 1.4x1 O' 13 cm 2 per bit (148 MeV protons). 

SUMMARY 

Testing of the 80386DX microprocessor for single event effects (SEE) has been 
discussed, along with the importance of this device to NASA's MSREP program and 
individual flight projects, such as Space Station Freedom. The capabilities of this device, 
as well as its widespread installed user base and available development tools make it 
highly desirable as one of the core elements in sophisticated flight computers, and for 
complex embedded controller applications. 

JPL's SEE testing shows that the 80386DX SEL threshold with heavy ions occurs at 
LET=40 MeV/(mg/cm 2 ). The SEU threshold LET=3.5 ±1 MeV/(mg/cm 2 ), and the soft 
error cross sections exceed 10" 6 cm 2 (100 square microns) per bit at LET=40. 

A test with 148 MeV protons, representative of trapped proton and flare proton energies, 
gives an SEU cross-section = 1.4xl0 13 cm 2 per bit. 

All tests were conducted at ambient temperature and worst case bias conditions. 
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APPENDIX A 

KNOWN 80386 DX REGISTERS 


SYSTEM LEVE L REGISTERS 

REGISTER NAME # ACTIVE BITS / REGISTER WIDTH COMMENTS 

Global Descriptor Table Register (GDTR) 

Interrupt Descriptor Table Register (IDTR) 

Local Descriptor Table Register (LDTR) 

Local Descriptor Table Segment Descriptor 
Task State Segment Register (TR) 

Task State Segment Descriptor 


CS Segment 
DS Segment 
ES Segment 
FS Segment 
GS Segment 
SS Segment 


Descriptor Cache 
Descriptor Cache 
Descriptor Cache 
Descriptor Cache 
Descriptor Cache 
Descriptor Cache 


Control Register 0 (CRO) 
Control Register 1 (CR1) 
Control Register 2 (CR2) 
Control Register 3 (CR3) 


Debug 

Debug 

Debug 

Debug 

Debug 

Debug 

Debug 

Debug 


Register 0 (DRO) 
Register 1 (DR1) 
Register 2 (DR2) 
Register 3 (DR3) 
Register 4 (DR4) 
Register 5 (DR5) 
Register 6 (DR6) 
Register 7 (DR7) 


Test Control Register (TR6) 

Test Status Register (TR7) 

Translation Lookaside Buffer (TLB) 


48/48 

Address and limit of the GDT 

48/48 

Address and limit of the IDT 

16/16 

Points to LDT descriptor entry in the GDT 

48/48 

Cached LDT descriptor entry in the GDT 

16/16 

Points to TSS descriptor entry in the GDT 

48/48 

Cached TSS descriptor entry in the GDT 

73/74 

Cached CS descriptor entry In the GDT 

72/74 

Cached DS descriptor entry in the GDT 

72/74 

Cached ES descriptor entry in the GDT 

72/74 

Cached FS descriptor entry in the GDT 

72/74 

Cached GS descriptor entry in the GDT 

73/74 

Cached SS descriptor entry in the GDT 

6/32 

System level control / status register 

0/32 

Not used - Intel reserved 

32/32 

Page fault linear address 

20/32 

Page directory base address 

32/32 

Linear breakpoint address 0 

32/32 

Linear breakpoint address 1 

32/32 

Linear breakpoint address 2 

32/32 

Linear breakpoint address 3 

0/32 

Not used - Intel reserved 

0/32 

Not used - Intel reserved 

7/32 

Breakpoint status 

27/32 

Breakpoint control 

28/32 

TLB test control 

23/32 

TLB test status 

1632/1632 

Paging cache 
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APPLICATI ON LEVEL R EG ISTERS 


REGISTER NAME # ACTIVE BITS / REGISTER WIDTH COMMENTS 


Extended AX Register (EAX) 32/32 

Extended BX Register (EBX) 32/32 

Extended CX Register (ECX) 32/32 

Extended DX Register (EDX) 32/32 

Extended Source Index Register (ESI) 32/32 
Extended Destination Index Register (EDI) 32/32 
Extended Base Pointer Register (EBP) 32/32 
Extended Stack Pointer Register (ESP) 32/32 

Extended Instruction Pointer Register (EIP) 32/32 

Extended Flags Register (EFLAGS) 32/32 

Code Segment Register (CS) 1 6/1 6 

Data Segment Register (DS) 1 6/1 6 

E-Space Segment Register (ES) 1 6/1 6 

F-Space Segment Register (FS) 16/16 

G-Space Segment Register (GS) 16/16 

Stack Segment Register (SS) 16/16 


Points to next code segment instruction 

Application level control / status register 

Code segment descriptor offset In the GDT 
Data segment descriptor offset in the GDT 
Data segment descriptor offset in the GDT 
Data segment descriptor offset in the GDT 
Data segment descriptor offset in the GDT 
Stack segment descriptor offset in the GDT 


HARDWARE LEVEL REGISTERS 

REGISTER NAME # ACTIVE BITS / REGISTER WIDTH 


Math Coprocessor Instruction Pointer 
Math Coprocessor Data Pointer 
Math Coprocessor Opcode 

48/40 

48/48 

11/11 

Linear Feedback Shift Register (LFSR) 

207/207 

Barrel Shifter 

64/64 

Pre-fetch queue 

128/128 

Instruction queue 

96/96 

Address bus latch 

34/34 

Data bus latch, output 

32/32 

Data bus latch, input 

32/32 
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